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I walked around and talked to the people working on the project, 
so that I could find out what they needed. Budget, schedule, 

and technical issues were all-important, but what often gets 
overlooked is how vou ^et a team to work together 
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Welcome to the Academy of Program and Project 
Leadership (APPL) and ASK Magazine. APPL helps 
NASA managers and project teams accomplish today’s 
missions and meet tomorrow’s challenges by providing 
performance enhancement services and tools, supporting 
career development programs, sponsoring knowledge 
sharing events and publications, and creating opportu- 
nities for project management collaboration with univer- 
sities, professional associations, industry partners, and 
other government agencies. 

ASK Magazine grew out of APPL's Knowledge 
Sharing Initiative. The stories that appear in ASK are 
written bv the "best of the best” project managers, 
primarily from NASA, but also from other government 
agencies and industry. These stories contain knowledge 
and wisdom that are transferable across projects. Who 
better than a project manager to help another project 
manager address a critical issue on a project? Big projects, 
small projects — they’re all here in ASK. 

Please direct all inquiries about ASK Magazine editorial 
policy to Todd Post, EduTech Ltd., 8455 Colesville Rd., 
Suite 930, Silver Spring, MD 20910, (301) 585-1030; or 
email to tpost@edutechltd.com. 
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IN THIS ISSUE Todd Post 


What Makes a Good Manager? 


This issue of ASK we look at several projects that recovered from serious 
problems after a critical change was made in how they were managed 


Nobody will be blinded by the brilliance of this 
insight: Projects often get into trouble because of how 
they are managed. Sometimes they recover; sometimes 
they don't. When the reason they recover stems directly 
from changes in management, that begs the question: 
What happened? 

We return to this theme over and over again in ASK. 
You may recall these remarks by Dr. Charles Pellerin in 
Issue 13, commenting on his tenure as NASA’s Director 
of Astrophysics: "I was frustrated that I couldn't antici- 
pate and recognize the difference between project 
managers who were going to succeed and project 
managers who were doomed to fail. We could predict 
things like sensor performance. We could understand 
the detectors. We could understand the power systems. 
But we couldn’t understand this one critical, invisible 
piece: What makes a good manager?" 

One approach to answering that question is bv 
looking at cases where project fortunes reversed 
following a change in managers. In “Bringing Up Babv," 
Gus Guastaferro remembers being asked to take over a 
research project in which the project manager he 
replaced was also the lead researcher. To achieve the 
promise of the prototype aircraft they were building. 
Guastaferro not only had to overcome management 
problems created by his predecessor, but to do it in such 
a way that did not compromise research goals. 

In another story, Alan Zak, a Vice President at 
Line6, tells of selecting a project manager to produce a 
new line of guitars. The project manager seemed to have 
what it takes — the technical smarts, an interest in project 
management, and, because he was a guitarist himself, an 
intimate understanding of the product — but he quickly 
found himself in over his head. Zak’s storv, “Sounds 
Clear Enough,” may well teach those a level or two above 
the project manager about how to recognize a problem 
situation before it unfolds. 


Mary Bothwell's story, “Walking the Fine Line,” 
picks up this theme from Alan Zak, but depicts a 
different approach to solve the problem. A division 
manager at the Jet Propulsion Laboratory’ (JPL), 
Bothwell was concerned that a change in management at 
a critical point in a project could prove more destructive 
than constructive. Bothwell’s story offers an interesting 
look at the paradox of how to positively impact what's 
happening within the project from outside it. How 
closely can upper management get involved before 
“micro-management” sets in? 

Managers change for reasons other than because 
projects get in trouble. People move on to other jobs, or 
they get promoted. In some of those cases, a project 
manager's job is simply to keep things on track. Such is the 
type of situation described by Steve Garber in his practice, 
"History: A Practicum.” Garber offers some practical 
insights on how to be a more effective communicator. 

In addition to all this, we have an interview with 
JPL’s Director of Flight Projects, Tom Gavin; a before 
and after story’ about a reengineering effort at the 
Hubble Control Center; and feature writers Terry Little 
and Scott Cameron return after getting a rest in Issue 1 6. 
The APPL spotlight this time is on the Project 
Management Development Process (PMDP). You may 
be surprised to find who’s talking up PMDP at NASA. 

While we may not have the definitive answer to “What 
makes a good manager?” — we believe this issue of ASK 
will contribute to your conversations about that subject. • 
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REVIEW BOARD 


JOHN BRUNSON of the Marshall Space Flight Center is a 
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Techniques in the Safety, Health and 
Independent Assessment Directorate at the 
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Senior Technical Staff to the NASA Chief 
Engineer at NASA Headquarters in Washington, 
D.C. He has received many honors and awards including the 
Exceptional Service Medal, Silver Snoopy Award, and various 
achievement awards. 

DR. OWEN GADEKEN is a Professor of Engineering Management 
at the Defense Acquisition University where he 
has taught Department of Defense program 
and project managers for over twenty years. He 
retired last year from the Air Force Reserve as a 
Colonel and Senior Reservist at the Air Force 
Office of Scientific Research. He is a frequent speaker at project 
management conferences and symposia. 


DR. GERALD MULENBURG is the Manager of the Aeronautics 
and Spaceflight Hardware Development 
Division at the NASA Ames Research Center. 
He has project management experience in 
airborne, spaceflight, and ground research 
projects with the Air Force, industry, and NASA. 
He also served as Executive Director of the California Math 
Science Task Force and as Assistant Director of the Lawrence 
Hall of Science. 


HARVEY SCHABES is currently assigned to the Systems 
Management Office at the Glenn Research 
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icing research, and since then has served in 
numerous organizations in support of the 
Space Station Program. 







DONALD MARGOLIES retired from the Goddard Space Flight 
Center in January 2004. He was Project 
Manager for the Advanced Composition 
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JOAN SALUTE is the Associate Director for projects in the 
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at Ames Research Center. She has managed many 
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at Ames for twenty years, and was awarded the Sloan Fellowship to 
attend Stanford Graduate School of Business. 



DR. MICHAEL HECHT has been with NASA since 1982 at the 
Jet Propulsion Laboratory GPL)- He is project 
manager and a co-investigator for the Mars 
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NASA’s New Millennium Program, he was 
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JODY ZALL KUSEK is a Senior Evaluation Officer at the World 
Bank. She is currently involved in supporting 
the efforts of seven governments to move to a 
focus of performance-based management. She 
has spent many years in the area of public 
sector reform, serving the Vice President of the 
United States, the U.S. Secretary of the Interior, and the U.S. 
Secretary of Energy in the areas of Strategic Planning and 
Performance Management. 





CHARLIE STEGEMOELLER is Manager of the Johnson Space 
Center CSC) Human Space Life Sciences 
Programs Office. He is responsible for the 
programmatic and tactical implementation of 
the lead center assignments for Space Medicine, 
Biomedical Research and Countermeasures, 
and Advanced Human Support Technology. He began his 
career at NASA in 1985 with JSC Comptroller’s Office as a 
technical program analyst. 

HUGH WOODWARD is a Program Manager for Global Business 
Services with the Procter & Gamble Company. 
He served as the Chairman of the Project 
Management Institute (PM I) for consecutive 
terms in 2000 and 2001 . He was elected to the 
Board of Directors in 1996, and before being 
elected as the chair, served terms as vice chair and in several 
other key leadership roles. 
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from the director's desk Dr. Edward Hoffman 


Well on Our Way 


A couple of years ago , I was sitting in my office talking with my 
Deputy Director Tony Maturo. We were in a contemplative mood, 
discussing NASA's then-recent run of prominent project failures 


I INDICATED THAT IF THE ACADEMY OF PROGRAM AND PROJECT 
Leadership (APPL) was going to significantly improve 
program and project management at In ASA, we needed to 
expand our portfolio of services, including resources that 
go directly to the project. “We need to be sending experts 
to the projects, experienced project practitioners, who can 
respond to the needs of the project manager,” 1 said. 

Tony smiled and said, “Okay, I know where you're 
going with this. But if we do what vou want, we need to 
do it right. I don’t want us to offer willy-nilly, do-what- 
you-want, feel-good stuff that costs a lot and makes 
absolutely no difference to a project.” 

I laughed because I knew exactly what he meant. I 
related a story' of mine from nearly twenty years earlier: 
In the mid-80s, I was responsible for providing 
organizational development support to NASA project 
teams. 1 was preparing to work with a new team and was 
conducting general interviews of the "what is working, 
what is not” variety'. A young woman seemed nervous 
about an upcoming retreat, and I asked about her 
concern. She blushed and asked me, “When we’re at the 
retreat, will we have to talk to a banana?” I had been 
prepared for many' things in my doctoral program at 
Columbia University, but they never told me how to 
respond to the banana question. 

She was serious. At a previous retreat, the facilitator 
had her team talking to bananas: "Speak to the banana 
as you would a new person joining the team...” 

Tony laughed at the story and said, "Exactly; if we're 
going to support project teams, let’s do it in a way that 
makes a clear difference.” 

While a training director in the Navy, Tony had been 
responsible for establishing rapid response support 
capability. His successful experience then provided us with 
manv lessons that we could use in our current situation. 


We outlined how we wanted to do this: First, we 
would gather a team of expert practitioners with top-gun 
status. I’m talking about experts with the ability to 
address all aspects of a project during any phase in its 
lifecycle. Second, we would work only to improve project 
capability' and competence — we were not going to 
supplement project staffing. Third, we would show we 
were serious bv responding within 48 hours to any 
request for our support and by following through on 
requests only when the project manager and team were 
committed to change. 

Moreover, we didn’t want to impose another layer of 
bureaucracy on projects, so we needed to establish simple 
procedures for obtaining our support. We also felt we had 
to measure project improvement in real terms, with data 
that could stand up to scientific scrutiny. 

That was the foundation for APPL’s Performance 
Enhancement business line, which presently accounts for 
just over half of all APPL business. Entering 2004, we 
were supporting 29 program and project teams in such 
areas as program control, project planning and sched- 
uling, systems management, risk management, project 
leadership, and culture/team improvement. Each project 
has been tracked with specific measures to indicate the 
value of our support. I have seen the initial measures and 
we will soon be unveiling findings indicating statistically 
significant improvements that should lead to wider 
discussions of how to develop and improve project teams 
and individuals. 

It is exciting and gratiiving to see and hear the 

O 0.0 

reaction of the NASA project community who has used 
these services. Based on customer reaction, increasing 
demand, and measurement of results, 1 think we’re well 
on our way to improving project management at NASA. 

And no one has to talk to a banana. • 


ASK 17 FOR PRACTITIONERS BY PRACTITIONERS 5 



■ 


6 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP 



W ' ' 


mm 

■ i :■]. 


BACK IN THE EARLY 1990s, REENGINEERING WAS ALL THE RAGE. ALL OF THE CORPORATIONS AND 
THEIR CEOs GOT EXCITED ABOUT THE PROSPECT OF HAVING TO STREAMLINE AND REORGANIZE, 
REENGINEERINGTHEIR ORGANIZATIONS IN AN EFFORT TO IMPROVE THE BOTTOM LINE. 



NASA Goddard Space Flight Center was no 
exception to that rule. Some folks in upper management 
wanted to take advantage of this new paradigm and they 
turned their attention to the Hubble Space Telescope 
ground system. The objective was to reduce the 
operating cost of the system by at least 50 percent. This 
was a noble objective, as Hubble would likely be around 
for another ten to fifteen years at least. 

When 1 first was approached by my branch head 
with the opportunity to lead this reengineering team, I 
said, "Well, that sounds good. I’ve done one of these 
before, and it sounds like a good challenge.” So, she put 
me on the project. What she didn't tell me was that I was 
the third person to lead the reengineering effort. The 
people before me hadn’t seen much success. 

When I came on the project, I spent some time 
getting a feel for the place and what the major issues 
were. I didn't try to reach conclusions about the hard 
decisions facing me right off the bat. Though people 
introduced me as the new project lead, 1 tried to stay in 
the background at first. This gave me the opportunity to 
observe what was going on and think about how I might 
need to change things. 

The first thing I noticed was there seemed to be a 
lack of cohesion, or "culture.” We didn't have any 
government on-site management; we had a consultant 
running the day-to-day activities. This person knew 
what he wanted to do, but he didn't seem to know how 
to go about it. We had a number of prototyping activities 
underway, but they seemed unfocused. In fact, it seemed 
more like a technical playpen than a project. The only 
schedule we had was a February 1997 deadline for 
completing the system update before the next Hubble 
servicing mission. Overall, the project simply needed 
better structure, methods, and processes. 

Though we were tasked with reengineering an old 
system, the project team largely consisted of people left 




BUDGET, SCHEDULE. AND TECHNICAL 
ISSUES ARE ALL-IMPORTANT, BUT WHAT 
OFTEN GETS OVERLOOKED IS HOW YOU 
GET A TEAM TO WORK TOGETHER. 


over from the original system development. At that time, 
Hubble senior management felt that the reengineering 
effort could be completed with the legacy staff alone. 
This assumption later proved to be erroneous. 

This is what I inherited in March of 1996 when 1 
came on board. 

PROJECTS ARE PEOPLE 

Yes, we had technical issues to address, but I concluded 
that I needed to concentrate first on the team itself if we 
were going to succeed. That was a strength that I think 1 
brought to my role as project manager. In my work on 
past projects, I felt that was where 1 had contributed the 
most, and I knew that I had good technical people on this 
project who would handle that side of the house for me. 

The project team had an alarming rate of attrition. I 
realized quickly that people were leaving out of frustra- 
tion because they' sensed a lack of direction. They felt 
that the management style of the consultant who had 
been in chaige was obstructing, rather than enabling, 
work. One of the first things I did was to fire him. 

I was able to convince our primary stakeholder that 
the project wasn't going to succeed with just the legacy 
people we had in place. She said, “Fine — go off and hire 
some new people; do whatever it takes.” I managed to 
bring in about fifteen people who had worked for me in 
the past, which allowed me some flexibility to start to 
fold and mold the project the way I felt it needed to be 


in order to get our work completed. The remainder of 
the revamped staff was provided by existing Hubble 
contractors, cold interviews, and “word of mouth.” At 
the peak of the project, we had over 150 people from 
fifteen different companies, plus NASA civil servants. It 
was a diverse group of people — from old to young and 
everything in between — and we were co-located, which 
was a good idea. 

I wanted to create a “badgeless” team. I 
know the word gets thrown around frequently, 
but we took it to extremes. Since we were co- 
located away from the main NASA Center, 

Goddard, it was easier to do. We were able to 
have people working together who hadn't 
worked together before because they were 
from different contractors. In a couple of cases 
we even had government people reporting to 
contractors. In the past, their management had 
said, "You can't work together.” Well, we let 
them work together. That was a start. 

However, it wasn’t achieved overnight and 
took a lot of energy and convincing by my 
management team and me before it stuck. 

We also flattened the organization. We got 
away from the hierarchical approach. We 
developed a series of product development 
teams, who were tied into the architecture that 
we developed. We then developed a work 
breakdown structure to start putting some 
process, structure, and schedules in place. The 
rewards quickly came; we started to look and 
feel like a cohesive project. 

As we did this, I walked around and talked 
to the people working on the project, so that I could find 
out what they needed. Budget, schedule, and technical 
issues were all-important, but what often gets 
overlooked is how you get a team to work together. How 
do you create order out of chaos? I hoped we could 
create, over time, a tight-knit community much like the 
old Cheers slogan, “A place where everybody knows your 
name.” One of my earliest initiatives to accomplish this 
was to have biweekly barbecues, which allowed folks to 
have a place to unwind a bit and to talk about things that 
had nothing to do with work. The idea was that in six 
months, when they would be delivering key components 
in a stressful integration environment, there would be an 
esprit de corps to carry us through those difficult times. 

Another of my initiatives I called the "kudos” 
program. After each major release produced by the team. 


I made a trip to my local grocery store to stock up on 
about twenty boxes of Kudos® bars. Then, I went to each 
individual personally and congratulated him or her on his 
contribution to our work. I would do that for all 150 
people. This became something of an “end job,” if you 
will, or an in-process, as far as the relationship that I had 
with my team. In fact, people started bringing me coupons 
for the next round of Kudos that I would be buying. 


WE SEE RESULTS 

Did it all work? I find it interesting that near the end of 
the summer, a little less than six months since I’d arrived, 
I was sitting quietly in my office, which was centrally 
located and always open, when I became aware of the 
hum and the vibration of energy out in the hallways. I 
could literally hear the team's cohesiveness. It was 
something of a mystical moment, I suppose, because I 
knew then, without a doubt, that the project was going 
to succeed. I was convinced of it based on the energy 
flow, the pulse, and the conversations that were 
occurring in the hallways on this particular day. 

In retrospect, when I look back on what was 
happening there, I can see that we had become the 
badgeless team I was aspiring for. We had gone from a 
hierarchical, structured environment, to teams who 



Mission accomplished: the Hubble Space Telescope as seen by 
the Space Shuttle Discovery after servicing in February 1997. 


THE MISTAKE OR CERTAINLY THE LESSON I LEARNED 
HERE IS THAT ONE NEEDS TO CONTINUE TO MANAGE 
EXPECTATIONS TO NEXT-GENERATION STAKEHOLDERS, 
AND TO DO IT RIGHT AWAY. 
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had the trust, confidence, and openness to stop in the 
hallways to discuss problems and make decisions 
without having to worry about any repercussions if 
they didn’t pass everything through their management 
team each time. 

An interesting side note to all of this was that over 
time the vocabulary of the project changed. Initiallv, 
there was a lot of “1" and “vou.” Over time, we noticed a 
subtle shift in the vocabulary to “us" and “we.” 

Not only did we meet our original milestone, but we 
had five major releases completed on time and on 
schedule. During that period, we delivered over one 
million lines of code. We were producing something on 
the order of fifteen lines of code an hour, where the 
accepted norm is closer to five. Our defect metrics were 
a third of the normal industry rate. This seemed great to 
me, but I wanted to be certain these metrics were real. 

I went to a group at Goddard who study software 
development. I asked them to take a look at the code we 
had produced. They spent a couple weeks analyzing our 
work, and came back and said that our team's work was 
some of the best they'd ever seen. So. technicallv, we 
were in good shape, which was what 1 figured. 

What about programmatically? Maybe there is a 
direct correlation between high technical productivity 
and the type of organization and team that vou put 
together. That would be nice to know. I got hold of 
another group who was putting together a project team 
development survey. 1 said, “Why don't vou take a look 
at our team? Come on over and give the survey to our 
team." We did that for a couple of days. They came back 
and said, “We have ten major criteria for very high 
successful teams. The average that we’ve seen so far is 
about three. Well, you guys have seven.” Even program- 
matically, we were off the charts. 

MANAGING EXPECTATIONS 

Despite all of the success that I’ve talked about, in 
August of 1998 I was replaced. We had a release due in 
June of that year, which we delivered on time and on 
schedule. Two months later, an organizational chart 
appeared, and 1 was gone. 

What happened is that the original stakeholder — 
the key supporter of the "radical management” 
philosophy — retired. New stakeholders came in, 
including a new program manager who had a 
background in management rather than svstems. I 
didn't think much about the change in stakeholders 
until the dav mv new boss came in and said, “We’re 


going to review why you have failed to deliver; the 
project is now in stand-down mode.” Evidently, there 
was a disconnect between what we had been asked to 
deliver by our former stakeholder, and what our new 
stakeholder expected to find. The mistake or certainly 
the lesson I learned here is that one needs to continue 
to manage expectations to next-generation stake- 
holders, and to do it right away. Don’t assume that thev 
know what you know. 

Perhaps 1 could have done a better job in presenting 
the case for our project team to the new stakeholders. If 
I had done a better job bringing my key people in to 
meet the stakeholders — presenting what we had done 
to-date, what the challenges ahead were, how we had 
accomplished what we had, and how effectively we 
worked — perhaps they might have had second thoughts 
and would have allowed us to continue. 

I’m not convinced that would have helped, though. 
It was clear that their expectations were very different 
than my expectations. They wanted to go back to the old 
way of doing business, one they felt comfortable with, 
specifically with the prime contractor managing a more 
traditionally structured project team. If the change had 
occurred a few months earlier, it would likely have had a 
devastating effect on productivity levels — but the change 

or. c> 

came when our initial development phase was almost 
completed. 

In retrospect, I can see that the project had reached 
a point where exceptional productivity wasn’t the 
highest priority anymore. We’ve all heard, again and 
again, that you have to know when things are good 
enough. It’s true in engineering — we don’t put twenty- 
nine bolts in where we need twelve — and it's true in 
project management. • 

Lessons 

• Nurturing a collaborative culture on a project can 
go a long way towards achieving tangible costs and 
schedule results. 

• Manage expectations, not only from the people 
working for you, but for the key people, i.e. stakeholders, 
that are above you. 

Question 

When would you prefer the collaborative leadership stvle 
depicted here, and when not? 
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WE JUST HAD TO BEAR DOWN AND DO IT. 
AND THE ONLY WAY WE WERE GOING TO 
GET THERE WAS BY WORKING TOGETHER. 




I SUSPECT THAT EVEN IF KEN HAD STAYED ON, WE WOULD HAVE EVOLVED TO THE STATE WE RE 
IN RIGHT NOW. IN TERMS OF THE NATURE OF THE WORK THAT WE’RE DOING, WE’VE GONE FROM 
DEVELOPMENT TO MAINTENANCE, AND SO THE PROJECT TEAM NEEDED TO EVOLVE TO REFLECT 


THAT CHANGE 


a hierarchical organization, decisions have to go through 
two or three levels of management to get approval. You 
tend to defer decisions as long as possible so you get the 
best answer with the most information. It takes longer, 
but bv the time the decision is made there is usually no 










were non-confrontational. Ken worked to make sure 
they weren’t. Questions came up, but there were fewer 
hostile challenges, like “Why the hell did you do that?” 
The questions were more along the line of, “Well, what 
else did you look at? Did you consider this?" This 
cultural change wasn't an easy thing to do, since it is 
always easier to be a critic than a contributor. 

We had one guy, in particular, who was an excellent 
engineer, but who loved to play devil's advocate. People 
like that can play a useful role on a project, but he 
simply came across as arrogant. People didn't want to 
talk when he was at a meeting. He impeded decision- 
making unintentionally, I believe, by intimidating 
people into not expressing their views. If you have 
someone who is constantly challenging a decision, you 
slow the process down. As a result, Ken had him 
removed from the project, which was probably the right 
thing from a productivity standpoint. The skill was 
there, but unfortunately his personality was damaging 
to the group effort. 

Ken didn't allow any one individual to stand in the 
way of getting the job done. We were in a phase where 
we knew what we had to do: reengineer an existing 
system. We just had to bear down and do it, and the only 
way we were going to get there was by working together. 

ONE PHASE ENDS 

It is the nature of project work that teams evolve and 
move on. As new development slowed, our budget and 
staffing were reduced, and we went from 150 people to 
around 40. A lot of the top performers gradually left the 
project. With the technical challenges on the project 
diminished, the need for creativity was no longer 
paramount. You can't keep highly enthusiastic people 
around if there's not enough for them to get excited 
about. Many wouldn’t have been happy in a mainte- 
nance mode anyway. 

In the transition from development to maintenance, 
we also ended up losing many of those exceptional 
characteristics of the project that enabled our high 
decision rate and productivity. Had Ken stayed around, 
we might have retained, who knows, more functionality 
in the system. As it stands, we’re still doing some 
technical upgrades because changes in the ground 


system are needed to support servicing missions and 
technology keeps changing, too. We try to fold in some 
new products and new capabilities, as well as implement 
some elements that were deferred earlier in the project 
because they were too costly. (Today, products exist that 
have made some of our former wish-list items feasible.) 
In a few cases, products we originally used in the system 
are no longer supported and must be replaced with 
current technologies. 

As Ken said, when our major stakeholder retired, 
the new stakeholders didn’t have the same goals as the 
old stakeholder. They weren't willing to accept the risk 
of keeping a radical project management approach in 
place. We all have our comfort zones, and it takes a 
great deal of courage to work outside of them. In all 
fairness, “radical" was understandably less acceptable 
in their career paths than it was in the career path of 
our former stakeholder, who knew that her next career 
move was retirement. We were lucky to have such a 
stakeholder in place at such a critical phase of the 
project’s life cycle. Could we have accomplished what 
we did without the radical changes to our management 
structure? I don't think so. 

We were on an aggressive schedule in development 
and, in response, we took aggressive steps to achieve our 
goals. A radical management approach may be 
something you can only sustain temporarily. But I think 
the results that came out of our experience on this 
project demonstrate the potential impact of adjusting 
management style to suit the real-time demands of a 
project. Our real challenge is making that possible. • 

Lessons 

• During a project life cycle, you must examine and 
question what management approaches are appropriate 
in the current phase. 

• To get maximum value out of meetings, make sure 
that the tenor of the group is cooperative enough so that 
everyone feels like they can express their views. 

Question 

For what type of decisions would you prefer aflat organization 
with quick informal processes? 
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OUR RESULTS DEMONSTRATE THE POTENTIAL IMPACT OF ADJUSTING 

MANAGEMENT STYLE TO SUIT THE REAL-TIME DEMANDS OF A PROJECT. 

' . 




YE SHALL NOT BREAK HUBBLE 

"On occasion, we would remind folks. By the way. this is a $2-billion national asset, and if something fails, you're going to get 
more visibility and more attention than you ever wanted." says KEN LEHTONEN of the Goddard Space Flight Center. Making 
certain that no one "broke ' the Hubble Space Telescope may have been his primary responsibility — but Lehtonen was intent on 
accomplishing far more than that. And as these stories attest, he indeed proved to be a talented "fixer" during his tenure as 
project manager on the reengineering effort of the telescope's control center. 



LEHTONEN 


In addition to managing the reengineering of the Hubble control center. Lehtonen has served as the project 
lead on the development of the International Solar-Terrestrial Physics ground and science data processing 
systems and. most recently, as the mission readiness manager on the Aqua. ICEsat. and Aura missions. 
Lehtonen has more than 35 years of experience in software engineering, including 20 years of "hands-on" 
experience developing software applications in the fields of orbit determination, image processing, real-time 
data capture, and data communications. 

LARRY BARRETT works for Orbital Sciences Corporation. He has more than 25 years of experience in all 
aspects of the system and software engineering life cycle. For the past six years, he has been the chief 
systems engineer for the Hubble control center system. 


Lehtonen and Barrett's stories in this issue of ASK are not the first time the two have publicly shared their 
experiences working together on the Hubble Space Telescope ground system. In 1999, they delivered a 
paper. “Culture Management on the Hubble Space Telescope Control Center Reengineering Project." at the 
30th Annual Project Management Institute Seminars and Symposium, and earlier in 2004 they published an article. "Managing 
a Product Development Team." in Program Manager. Their stories in ASK were based on an August 2003 presentation at the 
APPL Masters Forum. 



BARRETT 


Lehtonen can be reached by email at ken.lehtonen@nasa.gov. and Barrett at lbarrett@hst.nasa.gov. 
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My division was charged with building a suite 
of cameras for the Mars Exploration Rover 
(MER) project. We were building the science 
cameras on the mass assembly, the micro- 
scope camera, and the hazard and navigation 
cameras for the rovers. Not surprisingly, a lot 
of folks were paying attention to our work — because there’s really 
no point in landing on Mars if you can’t take pictures. 









BY MARY BOTHWELL 

In spring 2002 things were not looking good. day-to-day mentor. The deputy section manager actually 

The electronics weren’t coming in, and we had to go back took over running the schedule and realigned it to meet 

to the vendors. The vendors would change the design, the MER project's needs. 

send the boards back, and they wouldn’t work. On our 1 met with the instrument manager and the deputy 

side, we had an instrument manager in charge who 1 section manager every day for a while. We would go 

believe has the potential to become a great manager, but around the table and discuss the schedule. We had it on 

when things got behind schedule he didn't have the an 1 1x17 piece of paper that the deputy section manager 

experience to know what was needed to catch up. had put together. We went over every item. We would 

As division manager, I was ultimately responsible for say, “Okay camera number three — are you really going 

seeing that all my project and instrument managers into thermal vacuum today? Are you really ready to do 

delivered their work. I had to make the decision whether the calibration on camera number four today?” 

or not to replace him. With 650 people in my division, and a half-dozen to 

a dozen projects to track at any given time, I don't 
Insight from oversight usually get involved at this level on a project. I have 

After talking with the instrument manager's immediate neither the time nor inclination for this sort of heavy- 

supervisor, I could see that he was doing an excellent job handed management, but because the cameras were so 

of keeping people motivated and working despite the important, I had to get involved. 

challenges. For the morale of the team, 1 decided not to The instrument manager probably felt bad for a 

replace him — but 1 knew that he needed a little more month, but he knew that changes needed to be made, 

horsepower behind him. Let me make something clear here: We didn’t say, 

1 began working with the instrument manager "You're doing a terrible job.” We never used words 

and got the deputy section manager involved as his like, “If you don’t get these things done, you're fired.” 
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MER project staff drive a rover over staggered 
ramps in the laboratory to test the suspension's 
range of motion. 


A landscape taken by the Spirit rover's panoramic 
camera stretches west towards hills named after the 

A 1 n Cfy-rvrr nrrhc -nli/i 


Grissom Hill 
215° Azimuth 
7.5 Kilometers 
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Spirits panoramic camera captures an image of 
the rover's landing site, the Columbia Memorial 
Station at Gusev Crater. 


A rover sits at rest in the lab. 
The MER mission’s “eyes,” 
panoramic (Pancam) and 
navigational (Navcam) cameras, 
sit atop the rover's white mast. 


What we said at our meetings was more along the 
lines of "We have a problem here, and we need to find 
a way to succeed." 

Not only did I meet with the project team and 
management, but every day I would walk around to 
where members of the team were working and ask, 
"How’s it going now? Did you get that answer yet?” 

Because of that level of involvement, 1 knew what 
the challenges were so that I could forecast where the 


For the morale of the team, 
I decided not to replace 
him — but I knew that he 
needed a little more 
horsepower behind him. 


project might run into trouble. 1 am sure that I made a 
few lives miserable during this time. There was a little bit 
of, “Well, we really don’t have a problem. We're going to 
be able to fix this ourselves.” 

But once they figured out they couldn't get rid of me, 
they became forthcoming about the problems. If 1 saw 
someone in the hall and asked, "Hey how’s it going? Are 
you there?” I began hearing, "Oh yeah, we’re there,” or "Oh 
no, we didn’t quite make it and this is what we’re doing.” 
After several months, I was able to ease up, but I 
kept holding weekly meetings so that the team, down to 


the floor-level technician, knew that I remained engaged 
in the project. As a matter of fact, I remember that at one 
of these meetings, one of the technicians looked at me 
and asked, "Why are you pushing us so hard?" 

1 explained our position clearly to everyone at the 
meeting: We were the "eyes” for the entire mission; it 
would not and could not fly without our cameras. If we 
fell too far behind on our schedule, we would drag the 
entire project down with us. That technician didn’t 
complain again. 

Some people might think it courageous that he 
questioned me that way, but one of the things that I’ve 
always tried to do in my division is have an open door 
policy. Everyone knows they can come and talk to me 
about anything. They call me on the phone, and they 
know I answer my own phone. If they send an email, 
they know I’ll respond. They know that if they have to 
see me and I’m not around, that my assistant will work 
to find them time on my schedule. 

We are tested 

One of the things that I pushed the instrument 
manager on was asking if the team had enough people 
to complete the testing. We needed to do 24-hour 
qualification soaks on the cameras in a vacuum prior to 
science calibration. When we worked the schedule out 
and worked out the staffing that was required and 
looked at the two other projects that we had in thermal 
vacuum at the time, we realized that there weren’t 
enough people. Fortunately, we figured this out two 
weeks ahead, and not when there was no one to take a 
4 p.m. second shift. 
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We could have had the project team work 12-hour 
shifts in order to cover the testing schedule. But I noticed 
that we were starting to see them dragging, and they 
were already under so much pressure that I was 
concerned about them making mistakes. 1 decided to 
take some of the shifts mvself and I enlisted other 
managers who were capable of doing this work — so that 
we could give the team some relief during a time when 
the testing was not critical. Everyone 1 recruited had 
some past integration test experience. 

My time slot was 4 p.m. to midnight on Saturday 
and Sunday nights a couple of weekends in a row. You 
have to rearrange your life to do this, but it’s absolutely 
the right thing to do. We didn't need to use the subject 
matter experts. 

it wasn’t technically challenging work, and much of 
it was boring. You just sit there and take a measurement 
once an hour. We simply needed someone who could 
look at the scope and say, "It’s in-spec,” or “It’s out-of- 
spec.” If it was out-of-spec, you made a phone call and 
found out what to do next. I made a couple of phone 
calls on my shift when the temperature got a bit too high 
or too low, and was talked through the process so that I 
could adjust the temperature. 

By offering relief to the troops at this point, they 
were fresh for the part of the testing program where 
their expertise was absolutely critical. That’s something 
a project manager learns to do over time, and 
something that a project sponsor should always watch 
for. To ask, "Are we pushing our people too hard? Can 
we come up with an alternative solution that will keep 
us on schedule? Can we add outside people during 
non-critical times? Can we tell people who need a 
break to go home for the weekend?” 

And in the end... 

As we closed in on delivery, there came a point that my 
interactions with the instrument manager were more 
along the lines of, "Hi. How’s it going? We’re doing 
such-and-such test? Oh, okay. How do the scientists like 
it? Great.” Everything was just going fine. 

While we never caught up to the original schedule, 
the cameras were completed in time to be integrated 
onto the spacecraft and rovers. The instrument team 
delivered superb cameras that satisfied their customers, 
the scientists. 

After delivery, we had a partv. We rented a bowling 
alley, all of the lanes. Some of us threw strikes and some 
of us gutter balls, but we bowled together all afternoon 

O C? 


and had a wonderful time. We had much to celebrate, 
after all; the instrument manager and his team could feel 
proud of what thev’d accomplished. 

We had the opportunity to celebrate those accom- 
plishments, once again, after the successful Mars 
landings — with all the world looking at pictures our 
cameras had delivered. 

Lessons 

• Project sponsors must be prepared to move from 
monitoring to intervening when a project runs into 
trouble. Timing is everything; a project sponsor must 
recognize both when intervention is necessary and when 
it is no longer needed. 

• Effective managers demonstrate leadership bv supporting 

their teams — including nianagmg-by-walking- around and 
serving as a “soldier” when needed. • 

Question 

How do you draw the line between destructive micro-management 
and constructive, intensive help? 


LOOKING BACK 

Though she has years of experience 
behind her. MARY BOTHWELL of the 
Jet Propulsion Laboratory (JPL) hasn't 
forgotten what it was like to be a 
young manager on a troubled project. “I got an 
assignment to fly an instrument on the second flight of 
the Columbia.' she remembers. “Right when everyone 
thought that we were ready to go. we failed the pre- 
ship review. It was probably one of the most miserable 
periods of my life.” 

The “misery" didn't last, thankfully. When Bothwell’s 
instrument went back in the thermal vacuum for 
testing, the team was able to “prove the problem wasn't 
a problem." The instrument was shipped, and it flew — 
ultimately proving the validity of a new infrared 
measurement technique. “It started a whole new way of 
investigating mineralogy on the surfaces of planets." 
Bothwell explains. 

Today. Bothwell serves as manager of the 
Observational Systems Division at JPL. where she 
oversees the work of more than 600 managers, 
engineers, and technicians working on as many as a 
dozen projects at any one time. 
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Sounds Clear 



I'm a vice president at Line6, where 


we produce electronics for musical 


instruments. My company recently 


developed a guitar that can be 


programmed to sound like twenty- 


five different classic guitars— 


everything from a 1928 National 


Tricone" to a 1970 Martin. It is quite 


an amazing piece of technology. 


By Alan Zak 
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The guitar started as a research project because we 
needed to know if the technology was going to be viable 
and if the guitar design was going to be practical. I’ve 
been in this business for about twenty years now. and 1 
still enjoy starting up projects whenever the opportunity 
presents itself. During the research phase, 1 headed up 
the project myself. 

Once we completed our preliminary research and 
made the decision to move into development, that’s 
when I handed the project off— and that's where this 
story really begins. 

Orchestrating a hand-off 

We had an engineer, Dave, who had project manage- 
ment experience on comparatively smaller derivative 
projects, some of our more- or less-matured signal- 
processing gear. In that role he was performing well, and 
he had been brought in to help the researcher devel- 
oping the concept for the new guitar. When we made the 
decision to develop the guitar, Dave asked me if he could 
take over the project. 

When I kick off new initiatives like this one, I never 
take them to the finish line. 1 hand them off to a project 
manager already in the ranks, or I trv to mentor 
someone who’s just starting out in project management. 
The guitar project was going to run nine to twelve 
months, which is a relatively short span for our projects, 
and would only require a small team. It didn't seem too 
big a project to consider a new manager. 

I have to admit, though, that I had my concerns 
about handing off the project to Dave. He wanted to 
keep his hands in the firmware development, and 
become the project manager on top of that. There were 
many, many challenges in the project. Could we give the 
instruments an authentic sound? We had never done 
this. That was the first challenge. The second was that 
we weren’t simply dealing with electronics. As an instru- 
ment, the guitar required attention to aesthetics as well 


as its tactile qualities. It needed to be desirable for the 
customer from a “playability” standpoint. We might get 
our arms around it from an engineering vantage point, 
hut wp also needed to work with an outside manufac- 
turer for the body. 

Dave is certainly a competent engineer — but one of 
the problems we sometimes have with engineers is that 
their people skills aren’t strong enough to be effective 
project managers. Now, I knew' that Dave had a hard-core 
engineering background, but I also knew that he had 
worked well with his team when managing derivative 
programs. Plus, he was a guitarist himself. So, he had the 
enthusiasm I look for. The other thing that 1 suppose sold 
me is that he told me that he had been doing some soul- 
searching and looking at his career track and so forth, and 
he really wanted to develop his skills as a project manager. 

We talked about all of this a lot before 1 agreed to let 
him lead the project. I said, "You know, this can be 
difficult. If you want to do it, more power to you. We will 
try to help in any way we can, but if the situation does 
get to be more than you can handle, we need to know.” 

I gave Dave the project because he had a good track 
record. But I knew that I was introducing an element of 
risk to the project, because the scope was larger than 
what he had handled before. This was something we 
would need to watch carefully. 

Project discord 

Fast forward a few months: Dave did get himself into 
trouble. The main problem was that he wouldn't relin- 
quish his technical responsibilities. In essence, he was 
saying, “While I'm doing the engineering myself. I’m 
also going to be managing the project.’’ 

And he did deal well with the engineers and techni- 
cians on the program. But we also needed for him to be 
dealing with the manufacturing interests, supporting 
the subcontractors, looking ahead to the marketing 
aspects, keeping control of the financial planning, and 
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staying on schedule. There’s a reason that project 
management is a full-time job. 

Dealing with the body manufacturers in Korea and 
China, and integrating that with our own electronics 
manufacturing here in Los Angeles, came close to being 
a full-time job in itself. The electronics work was also 
experiencing some minor setbacks. As a result, the 
project was falling farther and farther behind schedule. I 
had to have some very frank discussions with Dave. “In 
my view,” I told him, “you're spreading yourself too thin.” 

Invariably, a young project manager will respond, 
"I’m not spreading myself too thin. I can keep this thing 
going, and it's going to get better. Just because 1 was here 
until midnight, you know, it doesn't really matter. Give me 
a week, you know, we’re going to turn this thing around.” 


badly flawed. 


In this case that went on for more than a month. 
From my perspective, it got worse and worse as we went. 
At last, I said, “Dave, if we get to this next milestone and 
it’s still apparent that you can’t function at the higher 
level of visibility that we need, we’re going to have to 
bring in some help.” 

I think the nail was put in the coffin when the 
production units arrived, and they were badly flawed. 
They were 50 to 60 percent unusable. At that point, I 
knew I had to bring in a new manager. 

Dealing with the dissonance 

It never is pleasant to replace a project manager, 
especially a young one, because you always, to a certain 
degree, hurt their feelings, their pride. I brought in a 
manager, Kevin, with a proven track record who was 
winding down work on a couple of other programs. He 
was the best project manager we had on staff. 

Earlier, when I had handed off the project to Dave, it 
was a natural progression. Kevin and I both understood 


that this second hand-off was very different; it was a 
sensitive matter. Kevin didn’t want to come in and usurp 
the good things that had been going on, including the 
camaraderie that had developed among the team 
members at that point. 

By telling their leader to step down, we might 
inadvertently be letting the team down, and the project 
could have unraveled quickly. Once things do start to 
unravel, I know from experience that sometimes you 
can’t put these things back together. My prime concern 
during the transition was to keep the team enthusiastic 
and highly motivated. 

The way I dealt with that was by staying involved 
after Kevin took over. I had as much open dialogue 
with the team as possible — with the schedule as a 
backdrop. In other words, when Kevin 
and I put together a new schedule, we 
didn’t foist it upon the team saying, 
"Look, you've got nine months. You had 
better make it happen.” No, it was a 
collaborative process. The team not only 
signed up for the new schedule, they 
authored it. Once we all had agreed on a 
schedule, I held regular weekly meetings 
with the team and the new project 
manager where we looked at the 
milestones against our schedule. 

And what of Dave? Yes, I replaced 
him as project manager, but I wasn’t 
saying, "You know, we’re just going to cast you aside and 
move on.” I believed that he still had much to offer the 
project, and that he was committed to see it through to 
the end. Dave remained on the project, but strictly in a 
firmware capacity. 

His first reaction was typical of what I usually see in 
cases like this. The project manger that’s being replaced 
says, “Well, okay, I understand. We've got to do what's best 
for the program." He understands that was a logically 
sound decision to make; but then the emotions kick in. In 
general, the people who work for us put their heart and 
soul into these projects. When they've been disappointed 
like Dave was, often they'll start acting out. Sometimes it's 
as benign as being a little less responsive. In extreme cases, 
they find ways to demoralize the rest of the team. 

This was not an extreme case. Dave’s bitterness, or 
resentment, simply had to be managed. I would say that his 
cooperation ebbed and flowed. In order to let the new 
project manager focus on more important issues, I took on 
the job of monitoring Dave’s attitude. 1 made an effort to 


I think the nail was put in the 


coffin when the production 


units arrived, and they were 
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work alongside him on occasion, so that 1 knew when I 
needed to take him out to lunch and have a talk with him, 
or when 1 needed to let things go to give him some space. 

The next movement 

In hindsight 1 can see that I made a mistake in picking 
Dave to be the original project manager. He had a good 
track record with smaller scope projects, but I misjudged 
the level of risk that I introduced to the project by 
selecting a manager whose experience had not prepared 
him for the magnitude of this particular project with its 
many interfaces — including manufacturing teams, off- 
shore contracting, and FCC oversight interfaces. 

I also had to relearn another lesson: Project manage- 
ment is a full-time job. If a project manager also wants to 
take on a technical role on the project, it must be a small, 
limited role — and not something in the critical path. If 
you have anyone trying to take on a managerial role, but 
they're also implicated in the critical path, really in all 
cases that's a recipe for difficulty if not disaster. 

Dave is still with our company, and still working 
productively. For now, I have made the decision that his 
future lies on the architecture side of our work. He 
might have thought that he wanted to be a project 
manager, but it became clear that his heart w'as still in the 
engineering. More than anything else, he wants to be 
working with the latest, greatest digital signal processing. 
So, he's very happy in that role. For now 7 , anyway. 


And what of the guitar? Even after the new manager 
came on board, we couldn’t get the project back on 
schedule. Early missteps are difficult to make up, and it 
was clear that in several respects we did not meet our 
objectives. One example: We didn't deliver in time to 
make our original marketing window. 

Still, I didn't let the project slip too far before inter- 
ceding. Ultimately, the project was saved. The guitar was 
delivered three months later than we had hoped, but it’s 
doing extremely well on the market. In fact, it was our 
most popular product in the industry 7 last year. • 


Lessons 

• Project management requires skills and experience, 


of all 


req 


attng sufficient 


quality 


time to the project. A novice project manager must 
understand that his or her new role will demand signifi- 


cant energy and time. 

• When a project manager is replaced, even if the transi- 
tion is handled in a timely fashion and with sufficient 
sensitivity, the project may still require a great deal of 
oversight on the part of project sponsors. Substituting 
one project manager for another should not be seen as a 
"quick-fix." 


Question 

Under what circumstances should a project sponsor remain 
closely involved in a project after a hand-off? 



JAMMING WITH ZAK 

“By using digital processing modeling techniques, we can make guitar amplifiers sound like any kind 
of vintage amplifier you could want,” explains ALAN ZAK, Vice President at Line6. Zak heads up 
electronics projects for musical instruments that “give musicians a larger sound palate to work with.” 
The guitar project he describes in his story, “Sounds Clear Enough,” is the Variax™: “Vari” as in various 
stringed instruments it can sound like; “ax" as in the term that guitarists use for their instrument. 

Guitar projects are a harmonious fit for Alan Zak. A musician himself, he has played and performed as a guitarist 
for much of his life. “When I was in high school, I played in several bands. I wasn't a world-class player, but eventu- 
ally I managed to get gigs opening for people like Ricky Nelson and George Jones." 

In his early 20s, Zak decided it was time to go back to school. After two years of engineering courses, he went 
to work for a startup music company and was involved in the invention of digital recording technologies and sound 
processing gear, obtaining three patents. “I was also doing a lot of project management. That's when I decided to go 
back to school to get a Bachelors degree in business.” (For the record, he also has two Masters — one in comparative 
philosophy, the other a MBA degree.) 

These days, Zak plays classical guitar — ironically eschewing the technologies he’s helped develop. “Technology 
is wonderful," explains Zak. “I think it’s great for recording and for sound reinforcement, but I’m still captivated by the 
simple musicality of playing." 
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BRINGING UP 


IN 1T77 / I jiasV -PwsUe^ eigUV yeows oh H\e 
\/l)<C.mG pvogrowH/ wUicU \w<*s ji\sf ^ vH^vwdoiAsly vtcU, 
■Po\sdH<*Hv\g ocp€vi€HC€/ using VUe vhosV up -+-o-<A<nf€ / 
sopUisHonfe^ vA<nn<ngevnenV. VecUni^ueS/ un<Aev- *nn 
ouVsVAH<Aing le^uAcv- n«M*\e<A jim MARTIN. /\-PV€v VUenV, 
you cou)<A s<ny VUe oppov+uniHes <nv<nil<nble ^ 
wtt-ktn NASA w sbvne vw^ys weve Wifi ess. 

\ 

I REMEMBER QUITE VIVIDLY WHEN I GOT THE PHONE CALL FROM ED CORTRIGHT, 
who was the Langley Center Director at the time, with news about my next 
assignment. He asked me to come to the aid of a project that was in trouble, the ■' 
Rotor Systems Research Aircraft (RSRA). 

"Are you sure you got the right guy?" 1 asked. "You've got so many 
aeronautical researchers at this center and you pick on me. I don’t know 
anything about this technology." i 

"This is not a misjtake,” he assured me. "You’re the person I want to do this.” 
t Cortright recognized that bringing this project to its end point would 
require someone wjth my skills — not necessarily me, but somebody like me 
who could drive the objectives of the program towards the plan already laid 
out. On Viking, we said we were going to land a spacecraft on Mars and do 
science there. Every decision we made was focused on that, so we learned to 
pay attention to our objectives. / 

Cortright’s concern was that unless someone \Svitft a real project 
background came in to deal with the contractor who was building the 
aircraft, it could become a continuous sandbox research program. They were 
trying to make the technology the best they could get it, and this was costing' 
a lot of money and a lot of time. It's like you're trying to get to 99-percent 
pure. Well, you have to learn sometimes that 95-percent will work, and that 
requires you to force-people to make decisions to get it done. 

The project manager was also the researcher who had designed this 
aircraft. The whole project was his idea. He had worked in helicopter 
research for 28 years. I would say he probably had spent seven or eight years 
getting the project approved. Then he spent another three years working on 
it. Altogether a decade of his ljfe was invested in this project. It was going to 
require a delicate touch for me to step in and help him understand that this 
was what was best for the project. I realized that this was his baby, there was 
no doubt about that, and I had to promise him that f was going to take care 
of his baby.’ f ' 
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One of the things that made this project exciting to 
me, and why I was keen to accept the challenge, was that 
in spite of decades of leadership in aeronautics, my 
center, Langley, had never designed its own fully 
integrated airplane, except for this one. 

I said to Cortright, "Well, before I say yes, let me go 
talk to the individual.” I told him that I wouldn't make a 
decision until 1 understood the problems, and I wanted to 
understand them from the project manager — not from a 
third party, but from the person running the project. 

A MEETING OF MINDS 

I went to see him. Nothing had been announced yet, and 
1 didn’t tell him I was considering taking over the project, 
but he knew something was up. He was not dumb. I was 
not there because I had nothing to do for lunch. 1 just 
said I was asked by the director to get a rundown of what 
he was doing. To his credit, the manager was forth- 
coming with details. 

So, I went back to Cortright and said, "I’ll take the 
job, if you still want to offer it to me because I under- 
stand what the challenges are and what the problems 
are. I believe I can help, but I want to keep the current 
manager as the chief engineer." 

When Cortright made the call to the project 
manager to tell him he was going to be replaced, 
I wanted him to explain it in no uncertain terms, 

TUey W eve Wylv\g Vo wwnUe VUe VecUwology 
VUe besV H\e y geV IV, VUls w<?vs 
cosHng c\ loV o-P wowey '°V o£ Hwe. 

"Hey, you're going to be replaced, but Gus would like to 
have you on his team. He needs you.” 

And it’s true, I did. It would have been very hard for 
me to take over this project without his smarts. I had a 
pretty' good sense of my own weaknesses. I didn’t come 
there as a helicopter research specialist. I was expected to 


step out of the space world, because remember Viking was 
an outer space mission, and enter this new world of 
aeronautics. I could have said I don’t need this person and 
gone out and hired a different chief engineer. My manage- 
ment would have supported it. 

But how you handle a transition like this is 
important. There was no guarantee my method was 
going to work, but I had previous experience in two 
situations like this where the manager was forced to 
leave and I had to take over, and I did not want to 
repeat what happened to me in either of those cases. 

FLASHBACK 

Once, 1 had to take over management of a critical 
resource without the help of the previous project 
manager because he was fired. It was then I learned how 
difficult it is to pick up where someone else has left off — 
without that person's knowledge to rely on. 

Another time, on Viking, I faced a situation similar to 
what I was facing on RSRA. In 1973, a little more than 
two years before launch we ran into problems with one 
of the instruments. Jim Martin said, "You’re no longer 
the management operations director. I’m putting you on 
this instrument, and you've got to go make it happen.” 

Again, I offered to make the instrument manager 
my chief engineer. I could have easily let him go, but I 
decided that he should still be on the team. I wanted to 
make him a part of the solution rather than a part of the 
problem. The worst thing is to say, "Hey, thanks for 
being around. Good luck. Have a good life,” and then 
walk away. That’s a big mistake. You have to be sensitive 
to that transition. Nobody likes to be replaced. 

Hence, I did the same thing that I did on the RSRA, 
but the difference was that the instrument manager on 
Viking wasn’t a researcher, he was a project type, and he 
never accepted the transition. He never did anything to 
hurt the project, or me, but he wasn't interested in 
helping either. I had to decide whether 1 would bring him 
along or let him go. Eventually, 1 found another position 
for him that allowed him to leave the project with dignity. 
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I learned an important lesson from this experience. 
When you see that there is a lack of interest, then you 
work hard at finding them a new place, another niche. 
You've got to get that person off your project and get 
them somewhere else. 

THE COOPERATION FACTOR 

There is no question in my mind that my job on RSRA 
would have been tougher without the cooperation of the 
project manager I replaced. It was certainlv a lot easier 
with him. He staved with me for about two months as 
my chief engineer, and he was just wonderful in terms of 
the transition. He understood my skills and what needed 
to be done, and was able to put his own ego on hold 
while he adapted to this new life. 

TUe icovsf FUing Is Fo sexy, "Hey, FU^nhV-s 
-Pev belvtg avrow\A. < ^’ <5<5 ‘^ lucV. H «nve <a 
goo A U-Pe/* cxaA Flven o\\Na\y. 

When you get in an environment where somebody 
has lost their baby like the RSRA researcher, and you do 
a good job in convincing them that they can still be a part 
of the solution, then you’ve done the right thing. The 
researcher on the RSRA believed in his baby so much 
that he accepted the fact that this transition was 
necessary- to be successful. He spent a lot of time giving 
me the technical aspects to do my job as best 1 could. 
What I gave him was an understanding of why this 
decision had to be made. 

Now I also had to show the team that I valued this 
individual. He was obviously well liked and respected as 
a technologist. I can't speak for the rest of the team, but 
I think they respected me for the fact that I didn't hurt 
their former leader. 

Right after 1 joined the project, I held a party-. The 
manager that I replaced came with his wife. You know, 
I sensed more hurt and sensitivity in his wife than 1 
ever did in him, and so I made sure to take her aside 
and let her know how important her husband was to 
the project and that he would certainly be sharing in 
its success. 

Thirteen months later. I'm proud to say that I lived 
up to my word. The day we had the first flight, he was 
standing right there with me. It was still his baby, and he 
had raised it well. He just needed a little help in getting 
it to college. • 


Lessons 

• You don’t want to lose key project knowledge. When 
a person being replaced has key project knowledge, 
seek ways to make sure that knowledge remains 
available to you. 

• Be sensitive during transitions. You don't know how 
emotional fallout will affect the project. Allow people to 
step out of their roles with dignity. 

• Don't overlook the teammates of a leader who is 
replaced. It is not your job to convince them that this is 
the right decision, but you should respect their feelings 
toward their colleague. 

Question 

How can you detect early on whether attempting to leave the 
replaced manager on hoard is going to be successful or not? 


STAYING IN TOUCH 

Following his work on the research 
project described in this story, 
ANGELO (GUS) GUASTAFERRO 

went on to serve as NASA Director 
for Planetary Programs, Deputy Director of the 
NASA Ames Research Center, and Vice President 
of Civil Space at Lockheed Martin. Now retired, 
Guastaferro’s decades of aerospace experience 
don’t go untapped: He continues to consult for 
NASA on future space systems and serves 'as 
Chairman Emeritus of the Hampton Roads 
Technology Council and Director of the Virginia 
Technology Alliances. 

In addition, Guastaferro’s work for APPL includes 
serving on the Advisory Board of the Leaders as 
Teachers & Mentors (LT&M) program, which 
leverages NASA's wealth of human and intellectual 
capital by connecting recognized program and 
project management experts in NASA and the 
aerospace industry to practitioners of all levels 
across the agency. LT&M participants, some active 
managers and some retired, reach beyond their 
immediate circle of colleagues to provide guest 
lecturing, teaching, consulting, and mentoring. 
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I had been in a technical/project management assignment about two years, when one day 
my boss asked me to come to his office to “discuss an opportunity.” When i arrived in his 
office, he indicated that the project manager of one of our biggest ($10M+) and most 
important projects had requested to be removed from the job immediately, and the organ- 
ization was going to grant the request. He felt I was the most experienced person he had 
and thought I would be a perfect fit for this job. 


This job would, no doubt, pose challenges. 
Engineering was near completion and most of the 
equipment was on site — but only 20% of construction 
had been completed. I would have just six weeks to 
complete construction, start up the facility, and begin 
production. I was flattered to be considered, but realisti- 
cally knew I had only done one similar, but smaller, 
project in my career. 

I had managed that project from the start to the 
end — so I had no experience with assuming another 
manager’s project. This assignment would be a three- 
to six-month job at a remote location. I would need to 


be on site in just two days, in order to have transition 
time with the old project manager. I worried this 
wouldn't be enough time to learn everything that I 
would need to know. 

After thinking it over for a night, I accepted the 
assignment, packed my bags, and arrived on site ready 
to debrief with the project manager — only to discover 
the project manager had decided not to return to the 
site. Thus, my transition time was zero. I focused, 
instead, on meeting the rest of the team and learned 
another key piece of the puzzle: There were serious 
interpersonal and functional issues within the team. 
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Team members were candid with me — many told 
me that they didn’t like other people on the team, or 
they wanted to be working outside their current 
functional areas. The R&D, engineering, construction, 
and manufacturing personnel had formed a variety of 
alliances amongst themselves, and none of these 
alliances were focused on getting the job completed on 
time to meet the business need. 

By noon on the first dav, I knew this was going to be 
an interesting challenge, to say the least. The good news 
was that the project files were organized and in good 
shape and the team members appeared competent. With 
the clock ticking, I also realized I didn’t have time to 
train new people. 1 decided to trust the remaining team 
members and focus on their strengths while trying to 
use each hour of every' day wisely to build team unitv. 

1 used the first two days to join up with each team 
member on a one-to-one basis to understand what he or 
she felt they needed to be successful. I used the informa- 
tion to define an execution strategy to meet the schedule, 
and then I began trying to break down the interpersonal 
and functional barriers I had inherited. These join-up 
meetings were a critical component for me to revise the 
existing execution strategy'. During these meetings 1 
discovered if an individual's success criteria were different 
than the team’s success criteria. Even though a person has 
agreed to the team’s criteria, they may actually be 
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motivated by other criteria, which could negatively impact 
the project. A one-to-one, face-to-face, join-up meeting 
was the only way I knew to build solid trust between the 
project manager and the team members. 

I also decided to not look back or focus on what 
caused the team to become segregated, but to focus on 
moving forward. Thus, I decided never to utter the 
words I have heard spoken often by project managers 
assuming an existing project: "You wouldn’t believe how 
screwed up this job was when 1 took over.” 
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After the first two days it was time to tackle the files 
to determine the technical scope and see yvhat omissions 
and cost issues, if any, we were facing. This strategy 
worked well and by the end of the yveek the team began 
to focus on what was needed to meet our timeline. We 
began a 24/7-work schedule yvith the project team and 
construction crew yvorking extended hours. As the davs 
passed, the team began to function better and began to 
pull together. We even made time for team-building 
activities, which yvere viewed positively and continued to 
sharpen our focus as a yvorking unit. 

To make a long story short, we performed a mirac- 
ulous turnaround, but missed the start-up date by a 
yveek. Instead of berating us for not meeting the original 
schedule, management yvas elated we came that close — 
considering yvhere yve yvere six weeks earlier. The team 
continued to yvork better and better yvith one another 
and, by the time the team disbanded twelve yveeks after 
start-up, it was a very cohesive unit. 

This experience taught me something that has been 
born out over time: A successful transition doesn’t 
necessarily lie in time spent yvith the exiting project 
manager. Don’t get me yvrong — that can be a big help. 
But the success of a transition actually lies in getting to 
knoyv the people you will be working yvith, under- 
standing their perceptions of yvhat is and isn’t working, 
and taking the time to read and analyze existing files to 
get a flavor of the project as yvell as the cost, schedule, 
and technical commitments that have been agreed to or 
modified over the course of the project. • 



W. SCOTT CAMERON is the Capital Systems 
Manager for the Food & Beverage Global 
Business Unit of Procter & Gamble. He is 
also a regular contributor to ASK Magazine. 
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PASSING THE BATON 

LESSONS IN REGRET 

By Terry Little 


I HAVE LED SIX MAJOR DEFENSE ACQUISITION PROGRAMS 

during my civil service career. For most of those, I was the 
first leader the program had and did not have to adjust to 
someone else’s legacy. This was both good and bad. 

The obvious good was that I was able, for the most 
part, to fashion things as I wanted them. These included 
patterns of interaction inside and outside the project 
office. I chose who would be in leadership positions. I 
developed the managerial philosophy and leadership 
vision. I decided my role vis-a-vis others in the office. 

I created the expectations and goals. The bad part was 
that all the while I was doing this I never considered 
what 1 might be leaving my successor to deal with. My 
reasoning was simple: I never intended to leave. I should 
have known better. 

Every time I left a program, it invariably went into a 
nosedive that lasted anywhere from a few months to, in 
one instance, more than two years. I could blame my 
successors for failing to pick up where 1 left off, but that 
would ignore the obvious. 1 was the common element in 
every case. I had failed miserably in preparing the way for 
my inevitable successor — failed five times! What had 
I done or not done? 

For one thing, I had adopted many non-standard 
practices which suited me, but would likely be unsuit- 
able for my successor. Consider earned value and 
metrics as an example. Because I did not agree with 
earned value and metrics, I simply did away with them. 
I worked on a face-to-face basis getting my information 
first hand and verbally. My way involved an amount of 
travel that any reasonable successor would simply not 
tolerate. Additionally, the DoD’s “best program manage- 
ment practices" places a lot of emphasis on using earned 
value and metrics as tools. Anyone replacing me would 
probably be adhering to these. 

The second thing I did was to make many manager- 
to-manager agreements that we never formalized in 
writing. They were just good faith understandings 
between two people. What happened when my 
successor arrived? There were no more understandings. 
My successors honored the written agreements, but had 


no allegiance to the unwritten ones I had made. 
The result was sometimes major turmoil. 

Third, I unconsciously fostered a tailored mentality 
among both the people who worked for me and the 
contractors’ project personnel. For instance, everyone 
knew that I was impatient with detail and wanted to get 
quickly to a bottom line that I could measure against my 
intuition for making decisions. Good for me, but bad for 
my successor — likely to be a more typical program 
manager who would expect detailed analysis. 

I also developed a somewhat deserved reputation as 
a bridge-burner. If one of my peers from outside the 
project office didn't agree with what 1 was doing, I simply 
went around or ignored him or her. It worked for me, but 
my successors had to rebuild lots of bridges, which took 
time, energy, and focus away from executing the project. 

I cared more for people's passion, loyalty, and their 
ability to get results than I did for how they did things. In 
that way, 1 put some real “odd-balls" in responsible 
positions. I was more than willing to sweep up any broken 
glass — a willingness that my successors did not share. 

Perhaps my worst fault was that 1 never groomed 
anyone to be my successor. I could have done that easily, 
but since I didn't intend to leave, it never occurred to me 
that I should do that. Some people take longer to learn 
from their mistakes. It has taken me failing to do this five 
times before I finally learned to begin a succession 
planning process in earnest starting from Day 1 . 

In a perfect world, a program or project would have 
one manager from birth to death. But we don't live in a 
perfect world. What should you take from all this? You 
decide. My conviction is that leading a project in a way 
that best allows a seamless transition to another leader 
at some uncertain time in the future is fundamental to 
project success. • 



TERRY LITTLE is the Director of the Kinetic 
Energy Boost Office at the Missile Defense Agency. 
One of the most seasoned program managers in DoD, 
he is also a regular contributor to ASK Magazine. 
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SPECIAL FEATURE: APPL’S PROJECT MANAGEMENT DEVELOPMENT PROCESS 
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program — and having received recognition fipir^^ .. 
trough ah four levels of it— I’ve had op po r t u nities 


— Rex Geveden, Deputy Director, 
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member of a team — often a functional expert, business 
manager, systems engineer, scientist, or project control 
agent. Level 1 portfolios are validated by a practitioner's 
immediate supervisor. 

Required training: APPL’s Foundations of Project 
Management class (or equivalency). Information about APPL 
classes, including schedules, is available in the Career 
Devebpment section of the APPL website, www.appl.nasa.gov. 

• PMDP LEVEL II: SUBSYSTEM LEAD 

Practitioners at this level have at least two years of 
project team experience (including two years as a 
subsystems lead) and must demonstrate the application 
of PM tools, techniques, and lexicon at the project 
subsystem level, including utilization of PM best 
practices. Level II portfolios are validated by the Center 
Peer Group and PMDP panel. 

Required training: APPL's Project Management and 
Systems Management classes (or equivalency). 


NASA’s COMPLEX AND HIGHLY TECHNICAL MISSIONS 
rely on effective project teams and managers. Since 
1993, through its Project Management Development 
Process (PMDP), the Academy of Program and 
Project Leadership (APPL) has offered direction to 
the Agency’s project practitioners as they advance in 
their careers. 

PMDP helps identify and sequence professional 
experiences, courses, and other project-based learning 
experiences that support individual career goals and 
center activities by outlining competencies at four levels 
of development. The result is that PMDP provides 
NASA project practitioners with a road map to the 
knowledge and competencies appropriate for their job — 
and the jobs to which they aspire. 

Plus, new this year, APPL has rolled out its 
electronic Project Management Development Process 
(ePMDP) tool, a learning management system that 
includes a dynamic presentation of the PMDP levels, 
competency areas, competency organizational struc- 
tures, Individual Development Plans (IDP), and online 
PMDP enrollment. 

APPL's website, www.appl.rutsa.gov, provides access to 
ePMDP, as well as other online resources for NASA practitioners 
enrolled in the Project Management Development Process. 

• PMDP LEVEL I: TEAM MEMBER 

At Level I, the project team member demonstrates an 
awareness and understanding of NASA’s project 
management (PM) tools, techniques, and lexicon. A 
Level I project practitioner is an active, contributing 

L. 


■ Developing NASA leadership 

I’m certified at Level I of PMDP, and I’m 
in the process of finishing up my certifi- 
cation for Level II. Though my title 
doesn't read “project manager,” I have 
come to realize that everything I do requires some sort of 
project management skills. 

Over the past couple of years, I have worked with the 
Integration Engineering Section for the International 
Space Station. Right now, Space Station is reorganizing, 




and I'm going to help out over on the operations side. We 
have limited resources, but high technical demands. 
Efficient project management is what ties those two 
together — and certainly the findings of the CAIB Report 
bear this out. As an Agency, we can't afford to base our 
decisions on a limited viewpoint (cost and schedule) when 
there are critical technical requirements that have to be met. 

It's important now that we use the CAIB Report to try 
to see what we need to do to become better as an 


an essential part of doing any agency job. Projects are at 
the heart of all of NASA's work. I encourage everyone in 
my division to be at least Level-ll certified, because it gives 
them a formal way of looking at and understanding 
project work by understanding how to deal with schedules, 
logistics, people, and all the rest. 

— Hector Delgado, Kennedy Space Center 



agency — and 1 think that the PMDP process supports this 
effort. Effective project management is key to getting us 
where we need to go. 

— Bill Stinson, Kennedy Space Center 

■rap 3 

• PMDP LEVEL III: PROJECT MANAGER 


Level III project mangers must have at least eight years of 

| 

project team experience and five years of successful 

j 

project management — in addition to demonstrating the 


• LEVEL IV: PROGRAM MANAGER 

Leaders with responsibility for a large agency-wide 
program must demonstrate strategic vision of PM 
principles, tools, techniques, and best practices. Level IV 
managers must exhibit the ability to manage a complex 
program or set of intricate projects with multiple associ- 
ated interfaces, performing appropriate trades across 
projects and providing reviews and recommendations to 
projects — including cost, schedule, and technical 
performance management. Program managers' PMDP 







portfolios are validated by the Center Peer Group, 
PMDP Panel and an agency-wide panel. 

Required training: APPL's Program Management and 
International Project Management classes. 


integration of PM tools, techniques, and best practices 
across subsystems at the project level. Level III portfolios 
are validated by the Center Peer Group and PMDP panel. 

Required training: APPL's Advanced Project Management 
class (or equivalency). 


e: m i. The path ahead 

I feature my Level IV PMDP certification 
. prominently in my resume and job appli- 
cations. I think my promotion to my 
current position and the one before this 
were directly influenced by my Level-IV PMDP certification. 
The leadership here certainly mentioned it frequently. 

The best part of PMDP is that a career development 
path is laid out for you. To some people it may look like 
you're merely “checking off" a list of requirements. In 
reality, as you go through the process, it turns out to be a 
strong enhancement to your career development. That's 
because it is put together by people who understand what 
it takes to move through the different levels of program 
and project management. So, if you take the pains to go 
through it, I really think you emerge from that process 
being highly suited to provide effective program and 
project management. 

— Rex Geveden, Marshall Space Flight Center 




Expanding horizons 

I started out in operations on the Shuttle 
i Program and for more than ten years 
J M I was a systems engineer on the floor. 
^ I went from a greenhorn apprentice 
working for a senior systems engineer to be a lead 
systems engineer with people working for me. 

At some point. I set a goal of becoming a project 
manager — and I knew there was a lot I needed to learn. 
So. I went and sought opportunities that would expand my 
exposure to project leadership. 

PMDP was part of that process for me. I received my 
Level III PMDP designation last year. In addition to what 
I've gained through the curriculum and hands-on experi- 
ence. I've benefited from all of the people that I've met 
through the process. Over the years that network has 
become invaluable to me. 

Not everyone wants to become a project manager, 
but I think that having project management experience is 








A PRACTICUM 


In the summer of 2002 , 1 was 
asked to serve as interim 
chief historian for NASA 
until a permanent replacement 
was hired. 


BY STEPHEN J. GARBER 


Rockr Launius, rill-: previous c;i 111:1 historian, had 
accepted a job offer from the Smithsonian. I guess you 
could say 1 was the logical person to step in while the 
search began for his replacement. 1 had been with the 
NASA History Office since 1995, and had worked closely 
with Roger. While not officially called his deputy, 1 suppose 
you could say I had functioned in large part as one. 

I had established and overseen a successful intern 
program in our office and had also worked with various 


outside historians as contractors; the work had piqued 
my interest in project management. I’ven though I 
understood my work as chief historian would be 
temporary, I looked at it as a good career opportunity. I 
enjoyed doing historical research and working on my 
own, but 1 wanted to improve my management skills. 

My time as acting chief historian and the experi- 
ences that led up to it have underscored a management 
principal that's worth repeating: Projects are people. 
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Practice One: Leverage your resources to 
create win-win situations for both you and 
your team members. 


Here is an example of some useful practical knowledge I 
gained managing a small project that 1 thought would 
serve me in good stead in my new assignment. Several 
years before 1 became the interim chief historian, I had 
been given the task of managing the History Office 
website, including supervising a small volunteer staff. We 
usually have one or two people who do some volunteer 
work for our office, and I used them to post new content 
to the site. 

Then there was this other person, Chris Gamble. 
He wasn't working as an official volunteer for us, but he 
spent a lot of time volunteering criticism about our 
website — especially regarding even- place he noticed a 
typographical error. I appreciated his feedback but I 
needed to find a better way to channel his help. 

It occurred to me that I should try to recruit Chris 
into doing something more proactive, and 1 asked him if 
he would be willing to look over some new Web pages 
before we "went live” with them. That way he could 
catch errors before they went public on the Web, rather 
than later. He agreed. 

After Chris had worked with us for a while, it wasn't 
such a big leap to ask him if he would be interested in 
preparing out-of-print publications for the Web in an 
electronic format. Since then, he has formatted literally 
dozens of books for us that are now available online. As 
a small token of our thanks, 1 send him free copies of all 

It's not as though Ive 

found a perfect solution, 
but I have learned to think 
through different options 
for communication. 

of our new publications — but he continues to work on a 
volunteer basis. If we were to hire a computer profes- 
sional to do all this HTML work, it would cost a lot 
more than we could afford. 

He’s done all this incredible volunteer work for us 
from his home in Switzerland. I’ve never met him in 
person, and I think I’ve spoken on the phone to him 
once; we communicate by email and snail mail. A happy 
ending to the story (although he continues to work with 


me) is that I nominated him for a prestigious NASA 
award, which he received. Afterwards, he wrote me a 
moving email, telling me how proud he is to be part of 
the NASA team. 

Sometimes when I'm having a bad day, I think 
about Chris Gamble. I’m just glad to work at an agency 
that engenders such enthusiasm from the public and in 
an office at NASA that gives me the flexibility- to leverage 
resources in unusual ways. 1 don’t think too many other 
people in government have the opportunity to tap such 
volunteer efforts. 


Practice Two: Because moving from team member 
to manager changes responsibilities, you may need 
to develop different communication strategies for 
dealing with people you already know. 


Personalities rub people different ways, and dealing with 
all the different personalities around me when 1 began 
working in the role of the chief historian was the big 
challenge I faced. Suddenly, I understood why, for 
example, Roger had clashed with certain people. Often 
I clashed with them, too. In the past I tended to vent or 
openly criticize other people I was unhappy with. 
1 realized quickly that as head of the department I 
couldn't afford to do that any longer; it would be 
counter-productive to our work, besides being unpro- 
fessional and unkind. 

Today, my communication style varies, depending 
on the person I’m dealing with. I like to use the coaching 
analogy: You’ve got to figure out what each player needs 
to stay motivated and productive; some may need 
reassurance, some “tough love,” and others “just the 
facts." In practice, though, I know that there’s not an 
easy answer for each personality. 

One person 1 work with, for example, kept calling 
me and wanted to have long phone conversations to 
discuss every little detail of the project he was working 
on. 1 began scheduling regular tag-up meetings and 
asked him to save all non-urgent items for our meetings. 
Then the tag-up meetings began running longer than I 
wanted. I began scheduling meetings with start and end 
times. I took a stronger role in leading the meetings and 
1 dosed the meetings on time. Our meetings became 
more efficient, but then I was concerned that we might 
not get around to covering everything we needed to 
cover. So, you see, it’s not as though I've found a perfect 
solution, but I have learned to think through different 
options for communication. 
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I often think back to two professors I knew in grad 
school. One taught a class on strategic management and 
pointed out that some people prefer to get their infor- 
mation verbally and some prefer the written form. This 
seems obvious, but I hadn’t thought about it that way 
before. At the time, I was a grad assistant for another 
professor who liked to call meetings with me and his 
other assistant to "chew the fat” for a while. These bull 
sessions seemed like a waste of time to me and I couldn't 
figure out why he liked to talk so much. I had wrongly 
assumed that because he was a researcher and writer, he 
always liked to get his information in written form. So 
the obvious moral to the story is that each person has a 
different communication style. 


Practice Three: Identify those people whose 
judgment you trust and be willing to seek 
out their advice. 


To get through this situation and others that have come 
up, 1 have relied on people around me for advice — often 
people 1 had known, but never turned to in the past. 
There is one particular person in my office that I’ve 
always thought of as a level-headed individual. 1 hope 
she doesn't mind that I’ve begun to use her as a 
sounding board. Indeed, it seems to have encouraged 
her to use me as a sounding board, as well, for things 
that she’s wrestling with. 

Roger was very good about offering to help after he 
left. Sometimes I turned to him to ask his advice on 
situations, even if I already had a good idea of how 1 
would handle them. 1 didn't call him with every little 


Finding mentors like these 
people has been helpful in 
grounding me, giving me 
perspective, and reinforcing 
my initial learnings. 

decision, but I talked to him when I thought a situation 
warranted extra attention. When he was still my boss, he 
had often asked me for my input on things. We seemed 
to be in sync in terms of our judgment in many cases. 

I also had lunch with the head of our History 
Advisory Committee a few times over the year I served as 
chief historian. I felt that it was a good thing to do when 
I was feeling a lot of stress or when I didn’t know how to 
handle certain situations. It wasn't as though he could 
offer any magic advice — but he is older than I, again has 
good judgment, and in general is a reasonable person 
with some gravitas. At first it surprised me when he would 
ask me personal questions like, “How is your wife doing? 
How is your health?” I wanted to focus our precious 
lunch hour on a host of work-related questions. But I 
quickly realized that talking about those personal things 
helped me to put any problems at work in perspective. 

Finding mentors like these people has been helpful 
in grounding me, giving me perspective, and reinforcing 
my initial leanings. 

The story ends, or perhaps it’s just a chapter 

In November of 2003, I finished my temporary assign- 
ment as the chief historian and handed off the job to Dr. 
Steven J. Dick. I've returned to my role as a senior 
member of the History Office. 

Was it a good year? I think so. Taking on a senior 
management position was a stretch for me, but knowing 
what I know now, 1 will be happv to stretch myself again 
when the right opportunity arises. • 


INTERVIEW 
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Thomas R, Gavin joined the Jet 
Propulsion Laboratory (JPL) in 1962. 
Currently the Associate Director of Flight 
Projects and Mission Success, he has 
garnered a long list of engineering 
and management positions, including 
serving as mission assurance manager for 
both the Voyager and Galileo projects, 
spacecraft system manager for the 
Cassini mission to Saturn, and deputy 
director for JPL's space and earth science 
programs. His previous assignment was 
director of space science flight projects. 
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INTERVIEW CONTINUED 



Technicians install the Huygens probe on the Cassini 
orbiter in the Payload Hazardous Servicing Facility. 


Gavin was honored in 2003 as a fellow of the 
American Astronautical Society at their national 
convention in Houston, Texas. He has received NASA’s 
Exceptional Service and Outstanding Leadership 
medals, and Aviation Week & Space Technology magazine’s 
Laurels Award for outstanding achievement in the field 
of space. 

You've been with JPL for 41 years. What were some of the 
early lessons you learned from the project managers you 
worked under? 

The technical challenges in those early days were 
immense. I learned from the early practitioners in the 
space program, such as John Casani, Bill Shipley, and 
Casey Mohl. They were all bright, disciplined thinkers 
who emphasized understanding problems in great 
technical depth. In fact, we're still following the princi- 
ples that they laid down 40 years ago. 

What is something that you learned from them that you 
still use today? 

Casey, for instance, would have coffee every morning in 
the cafeteria at 7:15 a.m. Everyone was welcome to 
come, sit down, have coffee, and ask questions. Guess 
what I do? People know that I come in to the cafeteria 
around 7:30 a.m., and, if they want to talk, they know 
where they can find me. 

Do you remember making mistakes or having missteps 
when you were working for any of those legendary 
project managers? If so, how did they respond? 

I was the mission assurance manager for the Voyager 
project and John Casani was the project manager. 
Casani has a very systematic approach in examining 


issues or problems. When you had to present a problem 
and the potential solution, Casani would very quickly 
work the discussion to the boundary of your under- 
standing of the issue. He always worked it with you so 
that you were discovering the soft spots in your 
solution. It was always a constructive learning experi- 
ence with Casani. 

So, the response wasn't to slap you down? 

No. It was very much to help me. I had the opportunity 
of a terrific on-the-job learning experience. 

So, you got to see the processes modeled? 

Yes. I learned incrementally. I absorbed it all, piece by 
piece. I didn't really have to think about what I needed 
to learn; I was lucky enough to see it modeled over time. 

We recognize that in today’s environment of short 
development schedules, engineers don't necessarily have 
the luxury of incremental learning. With new projects 
frequently on the horizon, we need to supplement their 
hands-on experience with training. 

To that end, we at JPL have compiled many years of 
experience in our Flight Project Practices and Design 
Principles and we have developed a project’s manager 
class — where the role and responsibilities of project 
management are explained to newly appointed and 
prospective project managers. This class is popular and 
provides a detailed look into the life of a project 
manager. As a result of this class, we have increased our 
pool of engineers ready for a project manager assign- 
ment, and we have also had engineers recognize that 
project management may not be for them. This 
unexpected outcome from this class is beneficial to both 
the employees and the Laboratory. 


The Voyager 2 spacecraft captures an image of 
Saturn's rings. 
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Uranus as seen from the Voyager 2 spacecraft. 


As someone whose responsibility it is to groom project 
managers, what do you look for? What do you expect in 
people who want to be project managers? 

First of all, they must have the necessary technical and 
leadership skills and personal integrity. 

You also must be able to inspire the confidence of 
the project team who is going to work for you. Take Pete 
Theisinger, the project manager of the Mars Exploration 
Rover, for example. He took on the job of launching two 
spacecraft from a dead start in 37 months. His team 
members had to have faith that he was going to lead them 
and look after them. Those are the qualities that I look for. 

How do you spot the real leaders? 

You have to watch their careers. What challenges have 
they faced? What commitments have they made and 
have they met those commitments? What have they 
delivered? In many ways, this is a natural selection 
process. Around here, if you say you want to be a project 
manager, the first question is always going to be: What 
experience do you have? What have you delivered? 

The fact that you want to be a project manager 
doesn't mean you are going to get the job. Part of the 


experience set for a project manager has to be delivery 
responsibility — what have you delivered successfully? 
Did you do it on time? Did you do it on money, be it 
hardware or software? 

In addition to delivery experience, we are looking 
for the total package. How were your communications 
skills? How did you deal with problems? How did you 
deal with stress? It’s those kinds of things. 

As you were going through that process yourself was 
there a point where you said, “This is going to make or 
break me"? 

Sure — again, for me it was Voyager. I was named mission 
assurance manager when I was 30 years old, and I was 
on the mission until it launched in 1977. Because of my 
work in the first couple years of the project, I was given 
responsibility for the radiation hardening of the space- 
craft from all of the mission’s electronics. They said, 
"Okay, you go do this job.” I had that development 
responsibility from 1974 until launch. 

Voyager leveraged everything in the rest of my life at 
JPL. On the other hand, if Voyager had not gone well, they 
might very well have said, "Well, we saw- what he did.” 
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INTERVIEW CONTINUED 


At the time, did you think you were in a little over your head? 
I thought I was in way over my head. I was thinking, "You 
want me to do what?" Voyager was a real stretch for me. 

Don't you think there's irony here? One of the things 
you're talking about is making certain that people are 
prepared to advance to the next level. On the other hand, 
you're talking about stretching, about making a leap. 
That's right. You’ve got to make people stretch a little. I 
decided early on that I love to run scared. Someone said 
to me once, "Why would you want to run scared?” I 
said, "Because it makes me think of all the things that 
could go wrong, so I can deal with them before they do." 

Voyager was my biggest stretch. With the Cassini 
project, on the other hand, there was no reason that I 
couldn't do well with that. I was the spacecraft manager 
for Cassini, and by that time I was well prepared for it. 

I'm sure you still found a way to scare yourself. 

I did. Before Cassini, I had always worked on the technical 
side of the house, where the emphasis was on meeting the 
engineering requirements first and foremost. Cost was 
secondary. Now I had a different role. That was the first 
time on a project that I had to manage the money, and it 
was definitely a stretch in that sense. So, I poured a lot of 
effort into learning about cost estimating and cost perform- 
ance. I stumbled for a while but ultimately succeeded. 

But in the end you returned money on Cassini. How did 
you manage that? 

Some people will argue that we just had a lot of money 
to work with. I would say we were disciplined. From the 
start on Cassini, I knew what reserves we had for the 
spacecraft. The budget was $611 million, and $71 
million of that was reserve. We made a series of decisions 
about how we would implement the project, and what 
type of management systems we would put in place to 
make certain we understood where the money was. 

We did a lot of fixed-price contracting, for example. 
So, we said, "Let's make sure we get the requirements 
right the first time, because if we fix-price this and then 
we go back and change requirements, we're going to 
hemorrhage money." Some of the contractors bet that we 
couldn't discipline ourselves, but we did. We spent the 
first two years of the project making certain we under- 
stood the requirements and had the right design. 


So, you delivered the goods. Then you had to leave the 
project when it was time for operations. How does it feel 
to hand off a project to someone else? 

You just walk away from it. You get the new manage- 
ment ready, and then you walk away. 

It was interesting with Cassini because as we were 
approaching the launch, I would warn the younger staff, 
"You're about to experience a feeling of separation." 
There were as many as 700 of them on the project team 
at one point. I would say to them, "You've been working 
now for five or six years with all of these people. You're 
a part of this great Cassini team here at JPL. We’re going 
to launch it, and then all of this is going to go away. 
You're going to have a sense of loss. You need to be 
prepared for that.” 

How was it for you, personally? 

Actually, when we came back from Cassini, it was kind of 
funny. Just imagine it: You're the leader of the band. 
You've got everybody watching you. You're down at the 
Cape. You've got the headphones on and you're 
launching the spacecraft. Everybody is cheering and 
high-fiving, right? 

Then I get back to JPL and walk into my office. Do 
you know what I saw in the office? Boxes and boxes and 
boxes. The guy who was the manager for operations 
came by and said, "Hi, welcome back. When can you be 
out of here?" 

When I came back from Voyager, it was the same 
thing. I had been down at the Cape for four months. I 
showed back up at JPL, walked up to the Voyager 
Missions Support area and my badge wouldn't work. I 
rang the bell. The girl said to me, "Can I help you? Who 
are you and why are you here?" 

So, I guess the only way to get through that is to find the 
next project? 

That's right. Projects end. That's our reality. 

But I love it. Listen, we are privileged. Everybody 
who works for this agency is privileged. We're privileged 
to serve the American people the way we do. It sounds 
corny, but look at what the American people have 
allowed us to do. We need to do our very, very best. We 
should kick our personal interests aside. We're doing 
these things in the name of science and for the 
American people. I never forget that. • 
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from the editor-in-chief Dr Alexander Laufer 


Checkmate to Uncertainty 


Coping with project uncertainty requires , at times , surprising solutions. 

I recall a stoiy related to me by a project manager that illustrates just such a solu tion 


The project manager was overseeing the construction 
of a new complex of swimming pools for a university, 
when the school's athletic director asked him to also 
remodel the basketball arena. He'd never done a remod- 
eling project before, and this particular project was 
extensive. The entire arena needed 
an overhaul. He'd established a 
good relationship with the athletic 
director, and since his project was 
winding down, he agreed to tackle 
the remodeling job. 

One consideration in his 
planning was that the basketball 
stadium was used by many of the 
school's sports groups, so there 
was only a small window of 
opportunity to complete the 
job — the last three weeks of 
summer vacation. This timeline 
was nonnegotiable. 

His first draft of the project 
schedule required a one-month 
timeline to complete the remodel as proposed. Working 
with the athletic director, he reduced the scope of the 
project and drafted a schedule with several contractors 
working in parallel where possible. The three-week 
timeline could be met. 

He presented the initial plan to the school's admin- 
istration for approval. The plan had the last day free for 
any emergency that might arise (Figure 1). The adminis- 
trators, based on their experience with previous remod- 
eling jobs, asked for a revised plan with two days at the 
end for emergencies. What he gave them instead was a 
plan with no free days at the end. 

Why? After meeting with potential contractors, he 
found that it was impossible to accurately estimate the 
time needed for some of the remodeling tasks until the 


work had actually started. If one contractor exceeded the 
estimated time, for example, that would delay the start of 
the next contractor's work. The contractor who followed 
the first would not sit idle; instead he would move to 
another job, further delaying his start time and rendering 
the entire schedule useless. 

Prior to developing a schedule, 
he established two criteria to reduce 
uncertainty. First, he reached an 
agreement with the athletic director 
that there would be no changes to 
the project. Second, he would select 
his contractors on the basis of 
proven reliability, not just cost. 

The schedule had to absorb 
changes as work progressed 
without collapsing. He did this by 
inserting time buffers — a half- or 
full-day between tasks — to follow 
tasks that were on or close to the 
critical path and had a high 
probability of time overrun. These 
would allow him to absorb schedule changes without 
stressing the overall timeline. A bar chart depicting the 
project schedule would look like a checkerboard, with 
black squares representing planned tasks and white 
squares representing the time buffers (Figure 2). 

The result was excellent. While he did use some of 
the time buffers, he never had to change the scheduled 
start time of any of the contractors. This convinced the 
administration to adopt a "checkerboard” system for all 
future remodeling projects. 

The story 1 heard from this project manager demon- 
strates what I have seen time and again: Successful 
project managers create project schedules that can easily 
checkmate uncertainty by loosening the connections 
between uncertain tasks. • 


Figure 1: Proposed Initial Schedule 



Figure 2: The Checkerboard Schedide 
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